如果小明透過小華跟小新借錢，其實是小明跟小新借的!可是對於小新來說他到底是要找小華要錢還是找小明要錢呢?? 小明 -> 小華 -> 小新 ?? 小華 -> 小新 ?? 小明 -> 小新 ?? 這種錯中複雜的關係，到底要如何釐清呢?? 就讓迪米特來告訴你吧!
哈!終於來到了第六個原則了!!迪米特原則(Law of Demeter)，這個原則名稱聽起應該又個模糊了吧!!前幾天出了個 Liskov ，今天又來個 Demeter !!不過今天這個原則的概念非常簡單!就讓我們繼續看下去~

所謂的迪米特原則它的目的是解耦合，而這個原則又稱作『最小知識原則』。顧名思義:也就是當我們在設計一個類別時，這個類別必須要知道其他的方法或屬性是越少越好。知道得越多，危險越大!!所以還是什麼都不要知道最好?!不是啦~什麼都不知道豈不是什麼都不用作!!還是讓我們先往下看~

如果你在做一件事情需要你的A朋友幫忙，而這個A朋友根本無法幫你，需要去找B朋友，那麼當你需要這件需求時就去找A，而A再去找B。當某一天，你又需要做這件事情了(到底是什麼事啊!)，你一如往常的還是去找A，可是這時候B卻不在了。這時候身為人類的我們可能會再想想有沒有其他的方法。但是我們所寫的程式呢??他會去想其他的方法嗎? 應該不會吧!他應該會直接跟你跳 Exception 或著就當作沒這件事情，導致後來的事件全部出錯，而你也必須一個一個找才能找到兇手!!

這個原則(LoD)在我一開始寫Java的時候很都做得好，不過後來再寫C#的時候，好像就沒有做到了!也是今天再分享這個原則的時候才又想起!!可能M$他覺得他很強，不需要吧@@...我又離題了!

下圖是上面範例的圖解:

有了概念後，我來看一下程式範例，下面這個是違反了LoD:

ObjectA.ObjectB.ObjectC.DoSomething();

因為我們所作用的對象是 ObjectB ，至於 ObjectB 要怎麼實作或者他想要跟誰合作其實都不關我們的事情，我們只管跟 ObjectB 合作就好。所以像這種情況，要嘛就是我們直接跟 ObjectC 作用，要嘛就是 ObjectB 必須提供另一個 public 的 mehtod 給我們用!這樣一來，我們就只要確認我們到 ObjectB 這段就好。這個就是最少知識原則(迪米特原則)。

但是，這個原則也是有例外的時候，有一個設計模式(Design Pattern)- Façade 就是個例外。至於Façade是如何的例外呢?請容我下回再跟大家分享囉!!

文章導覽
全系列
上一篇
下一篇